…r cache to have behavior driven logic instead (#14)

Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are:
 - on first request, check the returned version in sotw if activating stable version. Also compute the version differently
 - in some cases, return full state in sotw. In other case don't return if the only change is deletion
 - compute the version differently

In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible).
In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself.
There are two main parts not yet fully merged:
 - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract
 - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile

Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>

…r cache to have behavior driven logic instead (#14)

Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are:
 - on first request, check the returned version in sotw if activating stable version. Also compute the version differently
 - in some cases, return full state in sotw. In other case don't return if the only change is deletion
 - compute the version differently

In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible).
In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself.
There are two main parts not yet fully merged:
 - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract
 - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile

Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>

…r cache to have behavior driven logic instead (#14)

Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are:
 - on first request, check the returned version in sotw if activating stable version. Also compute the version differently
 - in some cases, return full state in sotw. In other case don't return if the only change is deletion
 - compute the version differently

In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible).
In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself.
There are two main parts not yet fully merged:
 - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract
 - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile

Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>

…r cache to have behavior driven logic instead (#14)

Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are:
 - on first request, check the returned version in sotw if activating stable version. Also compute the version differently
 - in some cases, return full state in sotw. In other case don't return if the only change is deletion
 - compute the version differently

In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible).
In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself.
There are two main parts not yet fully merged:
 - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract
 - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile

Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>

…r cache to have behavior driven logic instead (#14)

Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are:
 - on first request, check the returned version in sotw if activating stable version. Also compute the version differently
 - in some cases, return full state in sotw. In other case don't return if the only change is deletion
 - compute the version differently

In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible).
In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself.
There are two main parts not yet fully merged:
 - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract
 - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile

Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>

…r cache to have behavior driven logic instead (#14)

Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are:
 - on first request, check the returned version in sotw if activating stable version. Also compute the version differently
 - in some cases, return full state in sotw. In other case don't return if the only change is deletion
 - compute the version differently

In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible).
In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself.
There are two main parts not yet fully merged:
 - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract
 - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile

Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>

…r cache to have behavior driven logic instead (#14)

Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are:
 - on first request, check the returned version in sotw if activating stable version. Also compute the version differently
 - in some cases, return full state in sotw. In other case don't return if the only change is deletion
 - compute the version differently

In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible).
In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself.
There are two main parts not yet fully merged:
 - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract
 - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile

Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>

…r cache to have behavior driven logic instead (#14)

Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are:
 - on first request, check the returned version in sotw if activating stable version. Also compute the version differently
 - in some cases, return full state in sotw. In other case don't return if the only change is deletion
 - compute the version differently

In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible).
In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself.
There are two main parts not yet fully merged:
 - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract
 - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile

Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>

…r cache to have behavior driven logic instead (#14)

Following the addition of stable version support in sotw, the remaining differences of behavior between sotw and delta are:
 - on first request, check the returned version in sotw if activating stable version. Also compute the version differently
 - in some cases, return full state in sotw. In other case don't return if the only change is deletion
 - compute the version differently

In this context, the code can now be mostly merged, apart from the type differences on requests and responses (which I think can be reduced to none soon, but requires more rework on simple side and would be somewhat backward incompatible).
In this PR, the linear cache no longer treats sotw and delta watches differently. They are tracked in the same maps and the changes and responses are computed in a common method. Differences in behavior (e.g. full state or which version to use) is now a functional attribute of the watch itself.
There are two main parts not yet fully merged:
 - changing the version in sotw when using stable versions. The requirement to prepend cache version prefix makes it harder to abstract
 - defining whether a change only removing resources should trigger a response. This could be made a functional flag but given its intersection with `fullStateResponses` seemed fragile

Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>